The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1a illustrates schematically how the IMS fits into the mobile network architecture in the case of a General Packet Radio Service (GPRS) access network. As shown in FIG. 1a control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer plane and through which signals are directed to/from user equipment, UE, accessing the network. The entities within the connectivity layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network, IP-CAN. The GPRS network includes various GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) 2 acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). The middle layer is the Control Layer 4, and at the top is the Application Layer 6.
The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5, which operate as SIP proxies within the IMS in the middle, Control Layer 4. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. The top, Application Layer 6 includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality
The IMS architecture makes it possible to deploy peer-to-peer applications where two or more users exchange data during a SIP session. Examples of such peer-to-peer applications include Multimedia Telephony (MMTel), Push to Talk over Cellular (PoC), streaming, real-time video sharing, file sharing, gaming etc. The transport connection(s) is (are) negotiated dynamically by means of the SIP/SDP protocol exchange between the two end points (user terminals).
However, in order to support such peer-to-peer applications, there are two basic requirements: (i) a mechanism is needed to selectively control the SIP signal flows associated with the IMS session(s) of a subscriber; and (ii) a functionality is needed to control the IP flows through the dynamically negotiated transport connections in order to apply an effective charging for usage of services.
To meet these requirements, 3GPP defined, during Release 7, a Policy and Charging Control (PCC) Architecture (see 3GPP TS 23.203). FIG. 1b presents the basic outline of the PCC architecture. The Application Function (AF) 16 is an element offering applications that require dynamic policy and/or charging control of bearer plane resources. Although the application services are initiated and service characteristics are negotiated at the Application Layer 6 (e.g. by an Application Server 7—see FIG. 1a), in the case of the IMS the P-CSCF plays the role of the AF 16 at the SIP signaling plane (Control Layer 4). A Policy and Charging Enforcement Function (PCEF) 12 in the Connectivity Layer 1 monitors service data flow and enforces network policy on the user plane traffic. The PCEF 12 also applies charging based on the monitored data flow and the charging policy applied. This information is provided to an Online Charging System 13 over the Gy interface. Within a GPRS access network, the PCEF 12 is located in the GGSN 2a. Within the Systems Architecture Evolution defined in 3GPP Release 8, the PCEF is located in the PDN gateway.
A Policy and Charging Rules Function (PCRF) 14 resides in between the AF 16 and the PCEF 12. The PCRF 14 is the entity that controls charging based on the monitored data flow. The PCRF 14 obtains rules relating to the charging policy to be applied for particular subscribers over the Sp interface from a Subscription Profile Repository (SPR) 18, which includes a database of subscriber information. The PCRF 14 installs these PCC rules at the PCEF 12 over the Gx interface. These ensure that only authorized media flows associated with the requested services are allowed. In addition, the PCC rules installed at the PCEF 12 ensure that the right bandwidth, charging and priority are applied through the right bearer.
Once session characteristics are negotiated between the communication peers and the session characteristics are authorized within the IMS Core Network 3a, the AF 16 provides to the PCRF 14 an authorization of bearer resources over the Rx interface so that the corresponding resource reservation can be authorized at the Connectivity Layer 1. Note that, depending on the capabilities of the User Equipment, the capabilities of the Connectivity Layer 1 and operator policies, the establishment of the bearer may be initiated by the network (the Bearer Control Mode for the IP-CAN is network-initiated), or may be initiated by the User (the Bearer Control Mode for the IP-CAN is UE-initiated).
An important consideration is the resources required for the session, particularly the bearer plane resources, which will impact on the Quality of Service (QoS) provided for the session (e.g. the data rate at which data is transferred between the end users). The term QoS is used to refer to those parameters of a requested or on-going session that determine the Quality of the session Service experienced by the end user. The bearer resources applied, such as the available bandwidth for the session, are the principal parameters that determine the QoS of a session.
3GPP has adopted the concept of a QoS Preconditions framework (as defined by the Internet Engineering Task Force, IETF, in RFC 3312) for use with IMS session establishment. QoS preconditions are constraints (e.g. constraints on the minimum resources that must be satisfied before the session can be established), which are introduced during the session initiation. The recipient of the session initiation request (e.g. SIP INVITE) generates an answer, but does not alert the user or otherwise proceed with session establishment until the QoS preconditions are met. A session that is established with QoS preconditions satisfied is referred to as a “QoS-Assured” session.
FIG. 2a illustrates the signal flows that occur in setting up a session when there are no QoS preconditions. The client and network entities indicated at the head of each column have the same reference numerals as shown in FIGS. 1a and 1b. At step 201 an IMS client A, registered with an IMS network A, sends a session initiation request in the form of a SIP INVITE, which is routed through the GGSN 2a and the PCRF 14 to the IMS Core network A. The SIP INVITE indicates that Client A wishes to initiate a session with IMS Client B, who is accessing IMS network B, but does not include any preconditions. The IMS Core A forwards the SIP INVITE to IMS Core B at step 202, and this is routed through the PCRF 14 and GGSN 2a of network B to Client B at step 203. Provided that Client B is registered with IMS network B, Client B's user terminal rings (step 204). At steps 205 to 207, a SIP 180 Ringing message is routed back through networks A and B to Client A, who returns a SIP PRACK acknowledgement (steps 208-210). The session establishment is then completed when the user answers and (step 211) and a SIP 200OK message is sent from Client B to Client A (steps 212-214), which is acknowledged by a SIP ACK message returned by Client A (steps 215-217). Note that since the QoS Precondition Framework was not used in the IMS Session set-up, the availability of specific QoS resources does not need to be ensured before the user is alerted.
FIG. 2b illustrates the signal flows that occur in the equivalent situation to that shown in FIG. 2a, but setting up a “QoS-Assured” session making use QoS preconditions. The client and network entities indicated at the head of each column have the same reference numerals as shown in FIGS. 1a and 1b. At step 221 IMS client A, sends a SIP INVITE, indicating that Client A wishes to initiate a session with IMS Client B, and including an indication of preconditions. At this stage the preconditions indicated are NOT MET (because no bearer resources have yet been assigned) and a media “inactive” indication is included in order to prevent media data signals from flowing. The IMS Core A forwards the SIP INVITE to IMS Core B at step 222, and this is routed on to Client B at step 223. At this point Client B's user terminal does not ring because QoS Preconditions are required and not yet fulfilled. Instead, at step 224 Client B responds with a SIP 183 Session Progress message. In this example, this includes a similar indication that the specified QoS preconditions are supported by Client B, but are likewise NOT MET and a media “inactive” indication. The SIP 183 message is routed back to Client A (steps 225 and 226), who returns a SIP PRACK acknowledgement (steps 227-229) and Client B responds by sending a SIP 200OK message to Client A (steps 230-232). The required bearer resources are then reserved for the session by both networks A and B (this step is not shown in FIG. 2b, but will be discussed in more detail in relation to embodiments of the invention below).
At step 233 Client A sends a SIP Update message once its required QoS resources are available, which includes an indication that the QoS preconditions are MET and an indication that the media is now “active”. That is to say that the QoS parameters assigned to the session by network A satisfy the QoS preconditions specified in the original SIP INVITE at step 221. The message is forwarded to client B (steps 234 and 235). In this example, at step 236 Client B has completed reservation of required QoS resources and responds with a SIP200OK message that includes a similar indication that the preconditions are MET and media is “active” based on the QoS parameters assigned to the session by network B, which is routed back to client A (steps 237 and 238). Client B's terminal can then ring (step 239) and send a SIP 180 Ringing message back to client A (steps 240-242). When Client B answers, at step 243, the session establishment is completed by Client B sending a SIP 200OK message (steps 244-246), which is acknowledged by a SIP ACK message returned by Client A (steps 247-249).
The set-up of a “QoS-Assured” session will not be completed until the required resources have been allocated to the session. Thus, to establish a “QoS-Assured” session, each client's user equipment UE (e.g. mobile terminal) must successfully establish a bearer for the media stream that complies with the QoS preconditions defined in the session initiation messages (steps 221 and 224 of FIG. 2b) before it can indicate a successful response to complete the session establishment and notify the other client or end point.
In the session set-up without QoS preconditions shown in FIG. 2a, the terminating Client B rings and answers at any time after receiving the initial INVITE, but if the originating side does not yet have the required resources to handle the IMS call, the user behind Client B will not get any response from the user behind Client A when it answers the call. This is what is known as “ghost ringing”. However, setting up a “QoS Assured” session, as shown in FIG. 2b, has the advantage of providing an effective and interoperable way of establishing IMS sessions without the risk of “ghost ringing”. This is because the terminating user (Client B in FIG. 2b) will not be alerted (terminal will not ring) until the required resources have been allocated to both end-points. Set-up of SIP sessions that do not use the “QoS Precondition” framework (as shown in FIG. 2a) presents a high risk of “ghost ringing”. In order to avoid such a risk, and the subsequent user complaints, an IMS network operator may decide to enforce the use of QoS Assured Sessions on its system (this may also be a requirement forming part of Inter-operator Service Level Agreements).
However, as the following examples indicate, it is not always possible to make use of “QoS Preconditions” in the establishment of a session.                A Push-to-talk over Cellular (PoC) client may be configured not to signal “QoS Preconditions” within the set-up of a PoC session (according to 3GPP technical report TR 23.979).        An external SIP client (i.e. external to the 3GPP networks domain) that does not support the QoS Precondition framework may try to establish a session with a 3GPP client. “QoS Preconditions” will not be used in this case.        A SIP Client that does not have access to the underlying bearer layers (for example, a client using a so-called split terminal) cannot make use of the “QoS Precondition” framework because it will not be notified when related resources become available.        
Users such as these, that do not support the QoS Precondition Framework, are not at present able to take part in sessions over the IMS domain, where the operators enforce QoS-Assured sessions.
The present invention has been conceived with the foregoing in mind.